The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Most event-based or event-driven networking and computing systems include some type of event compression mechanism to reduce the number of instances of an event that are reported. As used herein, the term “event” refers to a condition or occurrence. In computing systems, events are typically represented by event data that defines attributes of the event. For example, in communications networks, network devices are typically configured to generate event data in response to detecting a particular condition or occurrence and provide the event data for processing to another entity, such as a software layer associated with the network device.
An event compression mechanism is conventionally configured to intercept all instances of a particular type of event over a specified period of time, referred to herein as the “compression interval,” and report the occurrence of the event once, regardless of how many instances of the event occurred during the compression interval. For example, suppose that an event compressor is configured with a compression interval of sixty seconds. Suppose further that during the sixty second period, one hundred instances of the particular event occur.
The event compressor intercepts all one hundred instances of the particular event during the sixty second period and provides, e.g., to a software processing layer, a single report of the particular event. The one hundred instances of the event are typically “flushed” by the event compressor and not reported to the software processing layer. The event compressor may also be configured to report the number of instances of the particular event that are associated with the report. Thus, in the present example, the event compressor also specifies to the software processing layer that the particular event occurred one hundred times during the sixty second period of time, but without having to provide the event data for all one hundred instances. The actual time of each occurrence may also be provided with the reporting data, or discarded, depending upon the application.
The ratio of the number of instances of an event per report is referred to as the “compression ratio.” Thus, in the present example, the compression ratio is one hundred-to-one, since the one hundred instances were compressed into a single report.
Event compressors provide some significant benefits. In particular, in situations where a persistent condition causes the generation of large numbers of instances of events, an event compressor can reduce the number of duplicate events that are reported to higher layers, thereby providing more efficient processing of events. For example, in the context of a communications network where a network device has failed for a prolonged period of tine, an event compressor prevents large numbers of duplicate error events, typically in the form of error messages, from being generated periodically. In this situation, the duplicate error messages don't convey much additional useful information to administrative personnel, other than the fact that the condition that caused the error still exists. The event compressor can notify and give administrative personnel time to analyze and repair the problem, while avoiding the generation of large numbers of duplicate error messages that provide little added benefit.
Despite the advantages provided by event compressors, they are not without their drawbacks. In particular, compression intervals are typically implemented as static timers that are not easily changed. Moreover, selecting an optimal compression interval can be difficult. If the selected compression interval is too short (under compression), then there will be insufficient event compression, resulting in an excessive number of duplicate events being provided to higher layers. If the selected compression interval is too long (over compression), then the response time may be too slow, resulting in the error condition going undetected (and not addressed) for too long.
Many times a single compression interval is specified for all types of events, which further decreases the effectiveness of event compression, since different types of events may occur at different frequencies. Even if different compression intervals were used for different types of events, the frequency at which instances of any particular type of event may change over time, which reduces the effectiveness of event compression.
Based upon the foregoing, there is a need for an approach for determining compression intervals and performing event compression that does not suffer from the limitations in prior approaches. There is a particular need for an approach for performing event compression that is less likely to perform under compression or over compression of events.